在第一天，我們已經談過這個系列的整體目標與規劃。不過，在開始動手寫程式之前，我們得先釐清一個根本問題——大型語言模型（LLM）的 API 究竟能做什麼？我們該如何選擇與使用？又有哪些潛在限制需要注意？

本篇文章將以 OpenAI 為例，帶你系統性地認識當前主流 LLM API 的功能類型、使用方式與常見限制。理解這些基礎觀念後，即使將來轉換到其他平台（如 Claude、Gemini），或是嘗試自行部署本地模型，也能舉一反三，快速上手。

大型語言模型 API 的核心功能

目前主流的大型語言模型 API，大多採模組化設計，將不同任務類型以功能分類方式封裝，讓開發者能針對需求選擇合適的介面。我們以 OpenAI 為例，整理出幾個主要模組如下：

• Chat Completion：幾乎所有語言模型應用的核心模組，包括聊天機器人、任務助理、流程自動化、AI Agent 系統等，都是以 Chat Completion 為互動主引擎。它支援上下文記憶、多輪對話、系統角色提示與工具調用，是本系列的開發重點。
• Embedding：建構語意檢索、相似問答與內容推薦等功能的基礎。常見於 RAG 架構，將文件轉為向量，再進行相似度比對，以提升模型的回應準確性與知識延伸能力。
• Image / Audio：屬於多模態應用模型，支援圖像生成、語音辨識與文字轉語音等功能。若開發場景包含語音輸入、視覺輸出或互動介面，這類模型可強化使用者體驗。
• Moderation：用於內容安全過濾，雖然不是預設強制使用，但在公開平台或社群互動型應用中格外重要。透過預先檢查輸入或輸出內容，可避免不當訊息觸發模型錯誤或帶來平台風險。

除了 OpenAI，其他模型平台如 Anthropic（Claude）、Google（Gemini）、Meta（LLaMA）等也大多提供類似的功能模組。理解這些核心 API 分類，不僅有助於後續開發，也能讓你在平台切換、架構擴充或混合使用時更加靈活應對。

在本系列中，我們將以 Chat Completion 與 GPT 模型 為開發主軸，因為它是實作 AI 助理、對話機器人與 Agent 系統的核心元件，也是整合 RAG、外部工具、記憶模組與狀態控制邏輯的基礎。

GPT 系列模型比較

OpenAI 提供多種 GPT 模型，針對不同的效能、成本與應用需求進行區隔。選擇模型時，主要考量的差異包括：

• 理解能力與回應品質：模型的推理能力、回應精準度是否符合場景需求。
• 上下文長度：可處理的歷史訊息與文件長度上限。
• 回應速度與費用：回應延遲是否可接受、是否符合成本預算。
• 最新知識範圍：模型訓練資料的截止時間是否影響回答正確性。

以下為目前（2025 年 8 月）常用的 GPT 系列模型規格與價格比較：

OpenAI 不定期更新模型與定價策略，文中資訊可能隨時間有所變動。開發前請務必前往 OpenAI 官方 模型 與 定價 頁面確認最新資訊。

模型版本特色

GPT-5 與 GPT-4.1 系列皆提供 完整版、mini 版 與 nano 版，滿足不同層級的效能需求：

• 完整版：具備最完整的推理與生成能力，適合複雜應用與高精準度需求。
• mini 版：在「速度、成本與能力」之間取得平衡，適合多輪對話、知識檢索與一般推理任務。
• nano 版：強調「極低成本與即時回應」，雖然推理能力相對有限，但在即時語音、互動助理、邊緣運算等場景表現特別優勢。

基於成本與效能的綜合考量，本文後續的程式範例將以 gpt-4o-mini 作為主要示範模型。

Chat Completion API 的使用模式

Chat Completion API 是目前各大語言模型平台（如 OpenAI ChatGPT、Anthropic Claude、Google Gemini）廣泛採用的主要互動介面，也是開發 AI 對話應用的核心入口。

這類 API 採用訊息序列的方式傳遞上下文，基本結構如下：

{
  "model": "gpt-4o-mini",
  "messages": [
    { "role": "user", "content": "請幫我寫一個 fibonacci 函數" }
  ]
}

訊息以角色區分，並依時間順序排列，模型會根據整體對話脈絡進行回應。

Chat Completion API 支援兩種常見互動模式：

• 多輪對話互動 ：用來建構像 ChatGPT 一樣具備上下文記憶能力的對話體驗，支援角色設定與語境控制。
• 工具調用模式 ：透過 Function Calling 讓模型根據提示主動呼叫定義好的功能，並回傳結構化參數，作為後續邏輯處理的依據。

這些能力使 Chat Completion API 成為實作聊天機器人、AI 助理與智慧代理系統的基礎。後續內容將會逐步介紹如何串接 API、設計提示詞以及整合外部功能模組。

Responses API 是什麼？適合哪些開發場景？

OpenAI 在 2025 年推出的 Responses API，是一套整合「對話儲存」、「任務追蹤」與「非同步處理」的高階功能，主要目的是簡化多輪對話與工具協作流程中的狀態管理。

Responses API 特別適合以下應用情境：

• 多步驟任務流程：例如需要跨階段推理或連續決策的複雜任務。
• 多工具串接與追蹤：如 AI Agent 系統，需同時調用與管理多種外部工具。
• 長期對話紀錄保存：如客服助理、決策支援系統，必須保留上下文以維持一致性。

本質上，Responses API 是在 Chat Completion 之上，額外封裝了一層會話管理與狀態處理的機制，開發者無需手動維護 session、歷程訊息與工具結果，能快速上手並縮短整合開發時間。

不過，在本系列中，我們仍會以 Chat Completion 為核心，並自行設計紀錄與狀態邏輯，主要考量包括：

• 更高的可攜性與平台彈性：避免過度綁定在單一 API。
• 可自由整合其他框架與服務：方便與既有系統或第三方工具接軌。
• 有助於深入理解底層運作：更清楚掌握訊息流與狀態管理的細節。

若你的應用場景強烈依賴 OpenAI 生態系，Responses API 無疑是一項便利工具；但若目標是打造模組化、可擴展、跨平台的 AI 應用架構，我們仍建議從基礎出發，自行實作訊息流與對話狀態管理。這將有助於你更靈活地應對後續的系統整合與維運需求。

申請 OpenAI API 金鑰

在開始串接 OpenAI API 之前，我們需要先註冊帳號並取得一組 API 金鑰。這組金鑰將用於驗證你的 API 請求身份，是串接模型服務的必要憑證。

以下是建立 API Key 的步驟說明。

Step 1：前往 OpenAI Platform 並登入

打開瀏覽器，進入 OpenAI 的 開發者平台。若尚未註冊帳號，請點選右上角的「Sign up」註冊；已有帳號則點選「Log in」。

Step 2：進入 API 金鑰管理頁面

登入後，進入 API 金鑰管理頁面。

Step 3：建立新的 API 金鑰

點擊「+ Create new secret key」按鈕，輸入描述名稱（例如 my-dev-key），然後按下建立。

Step 4：複製 API 金鑰並妥善保存

建立完成後，系統會立即顯示一組以 sk- 開頭的金鑰。請務必立刻複製並妥善保存，因為頁面關閉後將無法再次查看該金鑰內容。

API 金鑰使用建議與管理

API 金鑰具備存取權限的重要憑證，請務必妥善管理與保護，建議遵守以下原則：

• 請勿將金鑰寫入程式碼中，建議儲存在 .env 檔案，並透過環境變數載入，或使用密碼管理工具集中管理。
• 開發、測試、正式環境應使用不同金鑰，便於權限控管與問題隔離。
• 若為團隊協作，可透過 OpenAI 提供的 Organization 管理功能 進行角色與權限分派。
• 建議前往 Billing Limits 設定每月使用上限，以避免意外產生過高費用。

完成以上設定後，即可開始測試 OpenAI API 串接流程。另外，若你是首次註冊帳號，OpenAI 通常會提供一定的免費試用額度，足以支援初期的開發與測試。你可以在 Usage 頁面，檢視目前用量與剩餘額度。

快速測試：使用 curl 呼叫 Chat Completion API

在完成 API Key 建立後，我們可以使用最基礎的 curl 指令，快速驗證 Chat Completion API 是否能正常運作。以下是一個簡單的測試範例：

curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer sk-xxxxx..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Hello, Open AI!"}
    ]
  }'

請將 sk-xxxxx... 替換為你實際取得的 API Key。上述請求會使用 gpt-4o-mini 模型，傳入一段使用者訊息，並等待模型產生回應。

若請求成功，將會收到一段 JSON 格式的回應，其中包含模型產生的回答內容。例如：

{
 "id": "chatcmpl-xxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
 "object": "chat.completion",
 "created": 1756684800,
 "model": "gpt-4o-mini-2024-07-18",
 "choices": [
   {
     "index": 0,
     "message": {
       "role": "assistant",
       "content": "Hello! How can I assist you today?",
       "refusal": null,
       "annotations": []
     },
     "logprobs": null,
     "finish_reason": "stop"
   }
 ],
 "usage": {
   "prompt_tokens": 12,
   "completion_tokens": 9,
   "total_tokens": 21,
   "prompt_tokens_details": {
     "cached_tokens": 0,
     "audio_tokens": 0
   },
   "completion_tokens_details": {
     "reasoning_tokens": 0,
     "audio_tokens": 0,
     "accepted_prediction_tokens": 0,
     "rejected_prediction_tokens": 0
   }
 },
 "service_tier": "default",
 "system_fingerprint": "fp_xxxxxxxxxx"
}

這段回應中，choices[0].message.content 即為模型的文字回答內容，而 usage 區段則提供 token 使用量的統計資訊，可用於後續進行費用估算與效能優化。

本範例使用 curl 作為測試工具，也可以改用 Postman、REST Client、或直接透過程式碼發送 API 請求。

使用限制與開發注意事項

在開發與部署 AI 應用時，除了理解語言模型的功能與能力，也必須注意相關的使用限制與潛在風險。以下是使用 OpenAI API 時需特別注意的幾個面向：

上下文長度限制

每個語言模型都有固定的 上下文長度（Context Window），即模型一次可處理的最大 token 數量。此限制涵蓋以下所有內容：

• 使用者訊息（messages）。
• 系統提示（system prompt）。
• 模型回應（response）。
• 工具定義與調用參數（functions / tool calls）。

若輸入超出模型的上下文限制，API 將回傳錯誤（如 context_length_exceeded），或自動截斷訊息內容，造成語意不完整或邏輯中斷。

呼叫頻率限制

OpenAI 對每個帳戶設定 API 呼叫頻率與 token 使用限制，常見指標包括：

• RPM（Requests per Minute）：每分鐘可發出的請求次數。
• TPM（Tokens per Minute）：每分鐘可處理的 token 數量。

不同帳戶等級（免費、付費、企業）擁有不同的限制。建議前往 Limits 頁面查詢帳號當前配額，以便調整請求策略或進行重試控制。

資料隱私與輸入風險

語言模型本質上是以輸入內容進行推論，因此在應用中務必評估資料敏感性。以下為實務建議：

• 一般帳戶的 API 請求資料 預設可能被用於模型訓練，僅企業帳戶（如 ChatGPT Enterprise、Azure OpenAI）可保證不被用於訓練。
• 避免傳送包含個資、財務數據或內部機密 等敏感資料。
• 可考慮進行資料脫敏處理（如名稱遮蔽、識別碼轉換）後再傳送至模型。
• 若應用涉及合規風險較高的領域（如金融、醫療），應導入額外的安全保護機制，例如加密傳輸、內容審查、審核流程與稽核記錄等。

違規內容檢查

OpenAI 提供專用的 Moderation API，可檢查輸入內容是否涉及暴力、仇恨、色情等違規訊息。

需要特別注意的是，Chat Completion API 並不會自動執行內容審查。若應用屬於開放式互動場景（如客服系統、社群回應、對話平台），建議採取下列做法：

• 在將使用者訊息傳送給模型前，先呼叫 Moderation API 檢查輸入內容。
• 根據檢查結果決定是否繼續傳遞給 GPT。
• 為違規情境設計替代回應（例如提示使用者重新輸入）。

透過主動式的內容審查與防範機制，可降低模型輸出不當內容的風險，並避免帳戶被限制或封鎖。

這些限制與注意事項不僅影響模型的使用穩定性，也與資料安全、法規合規與使用者體驗息息相關。建議在專案開發初期就納入設計考量，確保系統能穩定、安全地與語言模型整合。

小結

今天我們系統性介紹了 OpenAI API 的主要功能模組、GPT 模型版本差異、使用模式，以及在開發過程中需注意的限制與安全風險：

• OpenAI API 提供 Chat Completion、Embedding、Image/Audio、Moderation 等核心模組，能支援多輪對話、語意檢索、多模態應用與內容安全檢查。
• GPT 系列模型分為完整版、mini 與 nano，差異在效能、成本與應用場景；選用時需考量理解能力、上下文長度、回應速度與知識截止點。
• Chat Completion API 是最常用的互動介面，支援多輪對話與工具調用；進階的 Responses API 則提供對話狀態管理與非同步流程追蹤。
• 申請 API Key 是串接服務的第一步，需妥善管理、避免外洩，並可設定不同環境的金鑰與使用上限。
• 使用 API 時需注意上下文長度、呼叫頻率限制、資料隱私以及違規內容檢查，以確保系統的穩定性與合規性。

理解這些基礎知識後，我們已經具備操作 API 的全貌，接下來就能進入實作，逐步打造真正的 AI 應用。